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ABSTRACT 


In 1989 AMSAT-NA plans to launch the first 
of a series of low-earth orbit (LEO) sat- 
ellites dedicated to serving digital store- 
and-forward message handling. These satellites 
are quite small cubes,, approximately 230 cm (9 
inches) on a_ side weighing less than 10 kg; 
this small _ size has led to our calling the 
project MICROSAT. Despite the small size, the 
satellites are crammed with state-of -the-art 
electronics. This paper will review the 
development program leading to this design and 
some of the technical details as well as 
describing how the terrestrial user will make 
use of the resource. We are planning on the 
launch of 4 satellites using MICROSAT 
technology into LEO in early 1989, and several 
more launches over the next 2 years. 


A_BIT OF HISTORY 


In October 1981, the ARRL, AMRAD and AMSAT 
jointly hosted the first Networking Conference 
when packet radio was in its earliest period 
of development. Doug Lockhart (VE7APU) and the 
VADCG group had put the first TNCs into our 
hands. Hank Magnuski (KA6M) and the PPRS had 
the first digipeater on the air. In the DC. 
area a few of us (W4MIB, WB4JFI, K8MMO, W3IWI, 
KE3Z) were on the air making funny sounds. The 
seed was planted! 


On a warm sunny afternoon the following 
spring, at the AMSAT lab at NASA Goddard, I 
took Jan King (W3GEY) aside and told him of an 
idea I had. At the time we _ were building the 
AO-19 satellite which was to provide global 
scale communications from its vantage point in 
high earth orbit (HEO). My idea was to provide 
similar communications coverage from LEO using 
digital store-and-forward techniques, albeit 
not in real time. The basic idea was for the 
sender to uplink a message to the LEO 
satellite; then at a later time when it was in 
view of the recipient, it would be forwarded 
to him automatically. 


After some more design work, I enlisted the 
aid of Den Connors (KD2S)who was_ then 
spearheading the effort in Tucson which became 
known as TRPR. Den and I started beating the 
bushes for support for the program. When the 
ideas became known to AMSAT, some of the old 
timers accused us of having lost our minds 
with statements like “There aren’t more than a 


couple of hundred people on packet. Packet 
radio will never amount to anything. etcetera 
etcetera”. By the _ fall of 1982 we were 


starting to see some ground-swell of support, 
so Den and I scheduled a special meeting (to 
be held in conjunction with AMSAT’s ana) 
meetin which was to get inputs rom 
ayer ee n several groups on the PACSAT 
concept. The second purpose was totry tO see 
if we  couldn’t come up with a national 
protocol standard; the result was the adoption 
of AX.25 (for which some PEOPLE STILL blame 


me!). 


Soon thereafter we found a __ potential 
sponsor who needed PACSAT support to aid in 
disseminating information on __ technologies 
appropriate to developing countries and _ thus 
was formed a_ tie between AMSAT and _ the 
Volunteers in Technical Assistance (VITA) and 
Gary Garriot (WA9FMQ). The VITA PACSAT project 
enlisted the assistance of Harold Price 
(NK6K), Larry Kayser (VE3QB/WA3ZIA, now 
VE3PAZ) and a number of _. others. The 


VITA/PACSAT team decided to_ test their 
messaging — concepts on a__ UoSAT _ spacecraft 
resulting in  uo-1 l’s_ Digital Communications 


Experiment (DCE). The partnership between VITA 
and the UoSAT group has continued, and the 
UoSAT-D spacecraft (to be flown at the same 
time as our Microsats) is the culmination of 
that effort. 


In the meantime I told the Miki Nakayama 
(JRISWB) and Harry Yoneda (JAIANG) of JAMSAT 
of our design concepts. The JAMSAT/JARL team 
were able to implement many of these ideas in 
the mode "JD" hardware on the Japanese JAS-1 
(JO- 12) satellite. They also developed State- 

1200 BPS©. “PSK 


of-the-art reproducable | 

demodulator designs which have become 
important for future spacecraft designs. 
Unfortunately the negative power budget on JO- 
12 has Iimited the _ utility, of an otherwise 


excellent spacecraft. 


A photograph of the structural mode 
of the MICROSATsatellite. 


Figure 1. 
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For the next couple of years any idea_ of 
our building a PACSAT in the USA languished. 
First we were busy’ building the AO-13 
satellite .in  consor with AMSAT-DL The 
American dependence on the Space Shuttle and 
the lack of suitable launches on which we 
could hitchhike made opportunities few and far 
between. We looked at low-thrust motors using 
water or Freon propellants to lift us to a 
suitable LEO if we used the Shuttle’s GASCANSs. 
Two groups flew small satellites ejected from 
GASCANSs on the shuttle; one was NUSAT, built 
ey a of students and _ faculty at Weber State 

ollege in Ogden, Utah. Then with the loss of 
the Challenger, even those hopes for our 
building a PACSAT were dashed. 


THE BIRTH OF MICROSAT 


The scene now shifts to November, 1987 in a 
hotel room =in_ Detroit after the banquet at 
AMSAT’s annual meeting. Jan King, Bob McGwier 
(N4HY), Phil Karn (KA9Q) and I are sitting 
around at 1AM. Jan © starts. telling us of a 
concept that he and Gordon Hardman (KE3D) have 
been thinking about. It involves a very small, 
simple satellite, a 9" cube. He describes how 
five 8" x 8’ x 1.6” module “trays” would be 
stacked to make up the inner frame of a 
satellite. Then on the’ small 9” x 9" — solar 
panels would make up the outside skin. He told 
us that he believed he had several different 
potential launches that could Puen several of 
these cubes to LEO and asked us what we could 
do with the limited space. By 3 AM we had a 
conceptual design, we had done link margin 
calculations, we had selected a candidate CPU, 
and we had estimated size, weight and power 
requirements for each of the modules. The 
adrenalin flowing in our veins was at an all- 
time high! 


By early December we had refined the basic 
design. Dick Jansson (WD4FAB) had done a 
complete mechanical design. We hela a 
preliminary design review at the AMSAT office 
and decided we were GO! 


While all this was going on, contacts were 
made with Junior DeCastro (PY2BJO) of the 
Brazilian BRAMSAT group, Arturo Carou (LU1] AHC) 
of AMSAT-LU and with the NUSAT group at Weber 
State. Each agreed to join’ the team and _we 
settied on building four satellites: The 
AMSAT-NA and AMSAT-LU satellites would be 
classical PACSATs. The Weber State satellite 
would be a PACSAT augmented by a TV camera 
which would send down pictures encoded in 
normal AX.25 packet frames. The _ Brazilian 
satellite would be the DOVE (Digital Orbiting 
Voice Experiment) which would talk Voic 
bulletins which could be copied on a _ normal 
HT 


PACSAT AND ALOHA 


First we need to review a _ little — packet 
radio theory. Let us assume that the satellite 
operates with its transmitter and receiver on 
different bands so that the communications 
links are full-duplex. Let us also assume that 
there are many users, each with similar 


capabilities, who are spread out over the 
entire spacecraft “footprint”. Let us further 
assume that traffic is balanced -- whatever 


oes u to the spacecraft equals what comes 
doi Se the uplink and downlink’ channel 


capacity needs to be balanced. 


42 


Since the ground-based users are _ spread 
out, the cannot hear each other. Each will 
transmit at random in the hopes’ that _ his 
packets make it thru. This is the classic 
ALOHA network configuration with “hidden 
terminals”. It can be shown that collisions on 
the uplink channel will statistically reduce 
the channel capacity so that only (1/2e) = 
18.4% of the packets make it thru. Thus, the 
downlink (on which there are no collisions) 
can support about 5 times as much traffic as 
can a single, collision-limited uplink. 


There are two ways out of this dilemma. 
First, the uplink users could use a _ data _ rate 
about 5 times the downlink; this approach was 
taken by the AMSAT-DL designers of AO-13’s 
RUDAK experiment where a 2400 bit per second 
(BPS) uplink is balanced against a 400 BPS 
downlink. 


The second approach is to have Seed ee 
separate uplink receivers. The FO-12 satellite 
has four 1200 BPS uplink channels balancing 
one 1200 BPS downlink. 


MODEMS AND RADIOS FOR PACSAT 


For our PACSATs, we have allowed for both 
solutions to the ALOHA limit. Like FO-12, 
there are to be four user uplink channels, 
however each of which can be commanded to 
support 1200, 2400, 4800 and possibly 9600 BPS 
uplinks. T he downlink transmitter will — sta 
its life at 1200 BPS, but higher rates should 
be possible. 


Our design was heavily influenced by a 
decision we made early on: we would only use 
standards which were supported and available 
“off the shelf”. Thus when our PACSAT comes to 
life, the ground user _can_ use the identica 
hardware he uses for FO-12 today. The user’s 
uplink will be at 1200 BPS, Manchester-encoded 
FSK and the downlink will be 1200 BPS binary 
PSK. These standards are supported by the TAPR 
and G3RUH modems, by the myriad FO-12 modems 
available on Akihabara in Japan, and_ by _ the 
DSP modems that N4HY and I have been working 


on. 


These "mo" modulator in these modems plugs 
into the mike jack on a_= stock 2M _ FM _ radio, 
which we assume can be tuned in 5 kHz steps. 
The satellite link margins should be such that 
10-25 watts into an omnidirectional antenna 
should be adequate (providing everyone runs 
similar power). 


The "dem" demodulator plugs into an SSB- 
capable 70 cm receiver or all-mode 
transceiver, which needsto be tunablein 100 


Hz (or preferably finer) steps. The PSK 
downlink should be "Q5" even with an 
omnidirectional antenna, providing the local 


noise level is low. 


The spacecraft’s receiver has 15 kHz wide 
channels, regardless of the bit rate 
programmed at the spacecraft. The 1200 BPS 
data rate combined with an FM deviation of < 3 
kHz, plus doppler shift, plus 5 kHz steps on a 
typical FM — radio just fit the 15 kHz 
bandwidth. At some ater date owe will begin 
enabling selected uplink receiver channels for 
higher data rates (like 4800 BPS), but the 
user will now have to pre-steer the doppler 
and set his frequency more accurately than 5 
kHz. Also most stock FM radios will not pass 
the 4800 BPS data rates without significant 
modifications. 


ARD PACSAT 


Let us now discuss some of the features of 
the satellite’s architecture. The electronics 
is divided into modules, with the space inside 
each module being about 7.8” x 65” x 1.5”. 
The mechanical layout has _ five of these 
modules stacked atop each other as shown in 
Figure 2, which we will desctibe from top to 
bottom. 


2M uplink antenna 


RECEIVER 


TRANSMITTER 


70 cm downlink 
antenna 


Figure 2. PACSAT LAYOUT 
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The core of the receiver is the Motorola 
MC3362 single-chip FM receiver, couple with a 
stock NDK crystal filter with 15 kHz bandwidth 
centered at 10.7 MHz. The filter has very good 
skirts, with 80-90 dB ultimate rejection. The 
input to the 3362 is an IF in the 40-50 MHz 
range. The Ist LO in the 3362 is crystal 
controlled to mix to 10.7 MHz. Following the 
filter, the 3362’s second mixer is driven from 
a crystal controlled 8.9 MHz 2nd LO to produce 
a final IF of 1.8 MHz _ selected’ for _ best 
linearity o  f the MC3362’s F M detector 
(discriminator). 


The MC3362’s FM detector drives two matched 
data filters, each of which uses one section 
of a TLC274 CMOS op amp; the  2-pole 
Butterworth filters are optimized for 1200 and 
4800 BPS data rates. A CD4066 analog switch 
selects the output of one of the two _ filters 
to drive the data clipper section of the 3362. 
The appropriate filter is selected by the CPU. 


In addition, one section of the TLC274 
produces an analog signal in the §-2.5v range 
corresponding to the  user’s frequency (the 
“disc meter’) and another produces a_ §-2.5v 
analog signal corresponding to the user’s 
signal strength (the "S meter’). 


All this circuitry takes up 1.5” x 3” on 
the receiver’s circuit board and draws’ under 
20 mW (< 4 ma at =5V). This’ circuit is 
replicated five times to provide the 4 _— user 
uplink channels plus a command/control 
channel. 


The design of this portion of the receiver 
was done by W3IWI with invaluable inputs from 
Eric Gustavson (N7CL). 


In front of this bank of five FM _ IF - strips 
is a fairly conventional GaAsFET preamp with a 
noise figure < 1 dB. A _— narrow-band 3-stage 
helical -filter provides selectivity between 
the GaAsFET preamp and a_ dual-gate MOSFET 
mixer which is driven by a crystal-controlled 
LO at about 100 MHz. The output of the MOSFET 


(at 40-50 MHz) drives five emitter followers 
to provide isolation between the five FM IF 
stages. The design of these stages was done by 
Jim Vogler (WA7CIO) and W3IWI. 


The total power consumption for the entire 
receiver is about 150 mW... 


[As a side _ note -- the receiver modules 
designed for PACSAT have been made sare 
reproducable, with very few  “twiddles”. 
components, including the coils and iica 
filter are off-the-shelf’ items purchasable 
from sources like Digi-Key. It is anticipated 
that TAPR and/or AMSAT will make - single- 
channel receiver kits available for use’ in 
dedicated packet link applications if there is 
enough interest]. 


TSFR 
For PACSAT, this is a. cn ae module. TSFR 


means “this space for rent”, and is reserved 
for future expansion. 


POWER SYSTEM 
The Battery Charge Regulator (BCR) module 


contains t h e NiCd battery pack, the charger 
that conditions solar panel power to’ charge 
the __ batteries, and the switching regulators 


that produce the +5 and +10 v power needed by 
each module. The BCR and regulator design was 
done by Jon Bloom (KE3Z) with help from Gordon 
Hardman (KE3D). 


The solar panels make _ use of high- 
efficiency silicon cells with back-surface 
reflectors (BSR). BSR technology is new, but 
it allows for much higher efficiency; if a 
photon does not produce electricity as it 
passes thru the silicon on its way in, | the 
reflector allows a second chance to “grab” Le: 
The solar panel electrical and mechanical 
design was done by Jan King (W3GEY) and Dick 
Jansson (WD4FAB), and the solar panels are 
being produced under contract by Solarex. 


The price of space qualified NiCd batteries 
has become’ prohibitive,, so new, low _ cost 
approaches have been’ adopted. Larry Kayser 
(VE3PAZ) and his group in Ottawa proved with 
UO-11 that if good, commercial grade batteries 


were purchased, they could be flight 
qualified. The qualification procedure 
involves extensive cycling to characterize the 
charge-discharge curve and temperature 
performance, X-raying the batteries to look 
for internal structural flaws, then _ selecting 


only the best cells, and _ then finally potting 
the batteries. 


While the solar panels produce about 14 
watts, when averaged over a_ whole orbit (some 
time is spent in eclipse), and after losses in 
power conditioning about 7-10 watts iS 
available. 


CPU 


In many ways the flight computer is the key 
to PACSAT. At the time we were selecting the 
CPU, the SANDPAC group in San Diego were 
finishing the first pre-production tun_ of the 
new PS186 network switch. Based on _ their 
experience, we selected a similar 
architecture. The flight CPU is basedon the 
NEC CMOS V-40 CPU (quite similar to an 
80C188). The flight CPU includes EDAC (Error 
Detection and Correction) memory for storage 
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of critical software, plus bank-switched 
memory for data storage (i.e. “RAM Disk”). We 


hope to fly upwards of 10 Mbytes = on_- each 
PACSAT (limited only by available space and 
the price of memory chips). The CPU, when 


running hard draws about 2 watts of power. 


A companion paper by Lyle Johnson (WA7GXD) 
and Chuck Green (N@ADI) describes the CPU’s 
architecture in much more detail. A paper by 
Bob McGwier (N4HY) and Harold Price (NK6K) 
describes the multi-tasking software. Jim 
DeArras (WA4ONG) is converting Lyle and 

huck’s wire-wrapped prototype to multi-layer 
circuit board. The ROM-based bootloader to 
allow recovery from disasters has been written 
by Hugh Pett (VE3FLL) whose code had 
previously saved the day on UoSAT. 


GLUE 
The myriad mechanical details were all 
sorted out before we cut a_ single piece of 


metal by Dick Janssen (WD4FAB); Dick made 
extensive use of modern CAD techniques and all 
drawings were done with AutoCAD (see Figure 
3). In Boulder, Jeff Zerr has been shepherding 
the detailed mechanical layout and find what 
ieces don’t fit. A “show and tell” model was 
uilt by ???? with help from Dick Daniels, and 
a mechanical mockup for vibration testing has 
been built by Jeff Zerr. 


When we_ began’ developing the Microsat 
concept, we took a look at problems that had 
been major hassles on earlier satellites. High 


on the list were problems in building a wiring 


harness and testing individual modules. We 

TRANSMITTER also wanted a design that allowed a “cookie 

; : aed cutter” approach to manufacturing since we 

At the time of this writing, the anticipate a number of launches in the next 
transmitter is _ still in the design phase, so few years. We came to the conclusion that we 
some of these parameters may change. The needed to develop a_ bus-like wiring approach 
transmitter will be BPSK modulated, and will with all modules’ having similar interfaces, 


and we needed to minimize the number of wires. 
I took on the task of solving this problem and 
defining the electrical “glue” that holds the 
system together. 


have its power output changeable by ground 
command. The current plans are for two power 
levels, about I.5 or 4 watts. The transmitter 
starts out with a crystal oscillator at 109 
MHz, and is followed by two doublers to 436 
MHz. This design is being done by Stan Sjol 
(W2KD). Gordon Hardman (KE3Z) is working on a 
power amplifier using a Motorola MRF750 driver 
and a MRE752 output stage. The _ collector 
voltage on the driver stage will be command 


After exploring a number of options, the 
design we adopted was to use hi-rel DB25 25- 
pin connectors on each module and use a 25- 
wire bus made like a flexible printed circuit. 
Of the 25 wires, about 40% are used for power 


selected to be either the +5 or +10vbus to distribution, about 40% to carry packet data 
provide power agility. This collector voltage from the receiver to the CPU and from the CPU 
may be amplitude modulated to provide some to the transmitter, and the tinal 5 wires are 
time-domain shaping to minimize the used to let the CPU control functions in the 
transmitted bandwidth. Transmitter development individual modules and for analog telemetry. 


is also done in Canada by Bob Pepper 


being 
(VE2A0O). 
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Part of one of WDO4FAB’s drawings 
showing UICROSAT assembly details. 


Figure 3. 


44 


AART 


In order to squeeze all these command, 
control and telemetry functions into only five 
wires, we have built a very small (7 inches 
long!) LAN with the CPU acting as the network 
master node and each module being a slave 
node. Data communications from CPU to module 
consist of two byte packets; the first byte 
(with the MSB=1) addresses up to 128 slaves, 
and the second byte (with MSB=9) is a_  7-bit 
received data field to be passed to the module 
(RXD). On receipt of $a valid address, _ the 
module automatically sends back two _ 8-bit 
bytes (TXD) of data on another wire. All data 
is sent with normal asynchronous protocols. 


On the CPU = side, this async data is 
generated and received by the UART built into 
the V40 chip. The protocol is easily simulated 
on a PC, so testing each module does not 
require a complete working spacecraft. 


In each module, we use a_ clever IC: _ the 
Motorola MC14469F Addressable Asynchronous 
Receiver/Transmitter (AART). The 14469 is a 
44-pin surface mount part (also available as a 
40-pin conventional DIP) which implements the 
protocol just described with very few external 
arts. It has separate pins for the 7 address 
its, the 7 RXD bits and the 16 TXD bits. 


The 7 RXD_ bits are used for a number of 
functions. The MSB- of this word is_ used _ to 
select analog vs. digital functions, with the 
control data specified by the remaining 6 
bits. For digital functions, the 6. bits are 
treated as two 3-bit nibbles which constitute 
the address and data for three CD4099 
addressable latches, resulting in 24 bits of 
digital data being available for control 
functions in the module. 


When the MSB selects analog functions, the 
6 bits are taken as addresses for CD4052 CMOS 


analog multiplexer chips which decode 6 
discrete analog telemetry samples’ plus’ four 
thermistors. When a module is’ selected in 
analog mode, the selected analog’ signal is 


switched onto two wires (signal plus return) 
in the 25-wire bus, and when the module is de- 
selected the two wires are floated. A single, 
fast 8-bit @-2.5v A/D converter in the CPU 
handles all spacecraft analog telemetry. Each 
module is responsible for preconditioning its 
analog signals to fit the Q-2.5v range. 


including some op amps to 


All these parts, 
signals, plus the 


condition the thermistor 
DB25 spacecraft bus interface connector and 
tie-points for all signals needed in the 
modules are fitted onto a 7.8” x 1.5” _ board 
which is mounted against one wall of the 
module frame. The interface boards in each of 
the “slave”? modules are identical except that 
the AART_ chipp ‘1s piLapped to different 
addresses. This small board has been dubbed 
the AART board. It was designed by W3IWI and 
Bob Stricklin (N5BRG). Each board requires 5 
mW of power (about | ma at 5v). 


THE OTHER MICROSATS 
DOVE 


So far we have described the two Microsat 
PACSATs: those sponsored by AMSAT-NA and 
AMSAT-LU. The BRAMSAT DOVE spacecraft is still 
in the final design phases, but it will be 
built from many of the same pieces and_ will 
have the same general mechanical layout. DOVE 


will transmit its digitized voice signals in 
the 2M band with conventional FM modulation. 
Rather than designing a_ different receiver 
system, we have decided to have the command 
uplinks also on 2M; the DOVE transmitter will 
turn itself off every few minutes to listen 
for commands. Only the transmitter module is 
different for DOV As of the time of _ this 
writing we are planning to use differentially- 
encoded voice synthesis (e.g. “delta 
modulation’*) with up to 4-bit encoding of the 
differential data. Preliminary design on _ the 
speech synthesizer has been done by _ Bob 
McGwier (N4Y) and W3IWI and is being simulated 
using our DSP hardware. 


NUSAT 
The Weber State NUSAT MICROSAT is different 


mechanically from the PACSATs, shown in Figure 
4. 


24 uplink antenna 


TV CAMERA 
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79¢ m_ downlink 
antenna 


NUSAT LAYOUT 


Figure 4. 


The major difference is that NUSAT has a 
CCD TV camera in the top module. The TV camera 
is connected to a high-speed multi-channel 
“flash” A/D converter which can digitize 
incoming video signals at 10 MHz sample rate. 
Its data is stored in memory which can also be 
accessed by the CPU. The Weber TV camera 
module and CPU were placed in adjacent modules 
so that the memory could be easily’ dual- 
ported. 


The sample rate for the A/D converter and 
the input signal source can be selected by the 
CPU. The primary signal source is a CCD TV 
camera equipped with an electromechanical iris 
built into its lens. The iris’s aperture’ can 
also be controlled by the CPU. The camera’s 
field of view allows a 350 km_ square to _ be 
imaged from the satellite’s 800 km high orbit. 

The camera assembly occupies about 1/4 of the 
space in the module. It is planned to use 
video data compression techniques to minimize 
the downlink data requirements; Weber State 
and AMSAT-NA plan to have software to support 


these advanced video techniques available 
around launch time. 
Weber State also. plans to try a 1269 MHz 


video uplink. Video data from this uplink will 
be digitized by the “flash” A/D converter and 
loaded into the dual ported memory, just like 
data from the CCD camera. It is also hoped 
that the TV camera can be used as an_ visible 
and IR spectrometer covering the 400 to 2000 
micrometer wavelength band. 
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The other NUSAT_ modules are nearly 
identical to the PACSATs and NUSAT could be 
also turned into a PACSAT merely by loading 
different software. 


The Weber State team consists of a number 
of students, staff and faculty members from 
the Center for Aerospace Technology (CAST) 
including Bob Twiggs, Bob Summers and Chris 
Williams. 


THE FIRST MICROSAT LAUNCH 
AMSAT-NA and the UoSAT group have worked 


with the European Space Agency and 
Ariannespace to develop a new launch 
capability for very small satellites. This 


will be first tested on the  lJlaunch- of _ the 
SPOT-2 Earth Resources Satellite in~ early 
1989. On that flight there will be SIX small 
satellites -- our four Microsats and two 
somewhat larger UoSAT spacecraft. The orbit is 
nearly ideal -- sun synchronous at 800 km 
altitude, much like the Oscar-8 orbit. At mid- 
latitudes, passes will occur twice per day at 
predictable times around 10:30 A.M. and 10:30 
P.M. local time. 


USING THE MICROSAT SATELLITES 


As we mentioned before, our PACSATs and 
Weber State’s NUSAT use ordinary AX.25 packet 
protocols. To receive any of the three, you 
merely need to add a PSK demodulator to your 
70 cm receiver. The uplink requirements are 
modest and the same as FO-12. At a later time, 
when transmitter technology permits and_ user 


loading dictates, some of the receiver 
channels will be reprogrammed to higher 
speeds. But initially, if you are able to use 


the FO-12 satellite, then you are all set. 


The spacecraft software that you will see 
will be designed for message handling, and the 
code is being written by Bob McGwier (N4HY) 
with inputs from a number of us. The initial 
software will probably look very much like a 
WORLI/WA7MBL __ BBS — system, _ with a few 
enhancements. First of all, the prompt that 
the satellite will send to you will have two 


telemetry numbers in it -- these are your 
signal strength and discriminator meter 
readings. The discriminator meter should be 


invaluable in helping you center your signal 
in the receiver’s passbandand its use_ will 


become mandatory as we migrate to _ higher 
uplink speeds. The spacecraft software will 
support multiple, simultaneous users. There 
may be commands that allow you to request 
specific telemetry information from the 
satellite. 


I pera tes that much of the utility of 
these satellites will be as an augmentation of 


the terrestrial long-haul message 
forwarding networks. If this proves to be 
true, then fully automated gateway _ stations 
will make heavy use ) the satellite 
capabilities. 


Therefore it is important that we design 
both the ground-based and flight software to 
work together smoothly. We have had ongoing 
discussions with the writers of BBS code (like 
WORLI and WA7MBL) to make sure that both sides 
of the link will be read on launch day. In 
these . discussions we have been devising 
schemes so that the burden of maintaining 
routing information resides on the ground. New 
forwarding protocols in which the receiving 
station tells the sender what message 


46 


addresses it can handle are being defined. It 
is likely that these will be coupled. with 
heirarchial domain-oriented addressing schemes 
like are used by TCP/IP protocols. A user on 
the W3IWI BBS would have an address like 
W3XYZ@W3IWI.MD.USA and if I were operating as 
a gateway for the MD/VA/DE/PA/NJ area, I would 
be able to inform the spacecraft to send me 
any messages so addressed. 


At the same time that “connected” mode 
activity is going on, the _ satellite — will be 
sending UI “broadcast” (i.e. UNPROTO) frames 
with telemetry and bulletins of interest to 
all. On NUSAT, digitally encoded pictures of 
the earth will be sent as UI frames which will 
be reassembled by the user on the ground. 


THE FUTURE 


We have reason to believe that there are a 
number of launch opportunities to LEO for very 
small satellites. We have designed our 
Microsats to be easily reproducable. As new 
capabilities (perhaps 9600 or 19,200 BPS 
modems? Experiments to fit into the TSFR 
module? ) are developed, we feel there will be 
opportunities to fly them. 


We anticipate non-amateur uses of our 
technology. Initial discussions with 
scientists specializing in oceanography and 


seismology have shown that they have a_ need 
for low-cost data — collection systems from 
remote locations. We anticipate a scheme for a 
commercial licensee to “sell” our technology 
in these markets. Just like’ royalties from 
TAPR’s TNC2 project have provided resources 
for future development activities in packet 
radio, we hope that Microsat_ royal ties will 
provide a similar legacy for advancing amateur 
satellite technology. 


We also see that the Microsat_ technology 
provides a_ perfect way for fledgling space 
groups _ associated with other AMSAT 
organizations around the world and with 
universities to develop their own__ satellite 
programs. Don’t be surprised to see Microsats 
being built by people from many nations. 


The spacecraft operating software can be 
uploaded from the ground. As NK6K and N4HY 
discuss in their companion paper, the software 
we will be flying is the most complex ever 
attempted in the amateur satellite program. It 
probably will crash! We have designed in 
several safeguards to make this possible. With 
this flexibility, we also have the ability to 
try new things. Perhaps we will see new mail- 
handling protocols developed which use 
datagrams. Perhaps we will see a PACSAT 
programmed to be a TCP/IP FTP file server. As 
the old adage states: 


IT’S ONLY SOFTWARE ! 


PARTING COMMENTS AND ACKNOWLEDGMENTS 


The most important “glue”. that holds a 
project like this  togetkner is the project 
manager. We are indeed fortunate to have Jan 
King (W3GEY), with his wealth of experience, 
his contacts in the aerospace’ industry, his 
mother-hen persistence in reminding us of the 
rigors of space, and his compulsive 
personality to make sure everything happens. 


Jan’s “glue” binds together a team of high: 
strung, emotional prima donnas who are equall 
compulsive. Many of the team members have 


invested a lot of 3AM mornings working on this 
project! All the team members have had to 
wear very thick skins to withstand the FLAME 
ON! communications blasts some of us are prone 
to ‘emit. Bob Mcgwier, Dick Jansson aad Lyle 
Johnson all deserve special credit for service 
above and beyond the call of duty. 


This project has significant players spread 


out all over North America, with major 
activities in NJ, MD, VA, FL, CO, UT, AZ, TX 
and CA. Unfortunately amateur radio 
communications are inadequate to keep such a 
dispersed team working together. We have 
relied heavily on commercial electronic 
communication channels, particularly AMSAT’s 


network on GTE TeleMail and TAPR’s channels on 
CompuServe, plus a lot of phone calls. Every 
few months we get a number of the people in 
one place and lock the door to make - sure 
everyone REALLY understands what is happening. 


We have made heavy use of various CAD tools 
during the development activities. | Mechanical 
layout was done with AutoCAD. ORCAD . was 
heavily used for developing schematics, wiring 
lists, parts lists and _ net _lists. CAD PCB 
layout used Smartwork, ORCAD PCB and Tango. 
See Figure 5 for an axample of some of _ this 
use of CAD techniques. 
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We have done some 
higher-level networking for technical 
communications to move CAD data using my 
TOMCAT FTP file server which has a SLIP port 


in addition to being on the “real” network. 


experimentation using 


There are two organizations not mentioned 
earlier that have contributed a_ lot to _ this 
project: TAPR and the ARRL. For many of the 
volunteers working on this project the 
distinction between TAPR and AMSAT is’ fuzzy 
since they seem to wear two hats. In addition 
to the TAPRites working on this project, TAPR 
has made vital contributions of funds and 
hardware, without which we couldn’t make it. 
Special thanks to Andy Freeborn (NOCCZ) for 
helping to make the TAPR/AMSAT interface 
smooth. At the ARRL labs in Newington, Paul 
Rinaldo and Jon Bloom have made many vital 
contributions. 


From the AMSAT organization, two _ people 
deserve a_ lot of credit. Vern Riportella 
(WA2LQQ) was instrumental in arranging the 


AMSAT-LU and BRAMSAT participation in the 


project. Martha Saragovitz has acted as mother 
confessor, paid bills, handled meeting 
logistics and kept smiling thru it all, 
despite repeatedly crying out  “Where’s the 
money coming from?”. 
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